From david4602 at gmail.com  Wed Aug 17 11:42:23 2011
From: david4602 at gmail.com (Cathy Schmidt)
Date: Wed, 17 Aug 2011 11:42:23 -0400
Subject: [Apple3-L] Did a SmartPort driver ever get written for the ///?
Message-ID: <4E4BE15F.6020609@attglobal.net>

A question for the Sarasours out there... did a SmartPort driver ever 
get written for the ///?  The way this would be useful would be if a 
SmartPort adapter were plugged into an expansion slot, the standard 
SmartPort/ProDOS interface could be rerouted through a SOS block device 
driver.  It wouldn't even need to be specific to a particular device... 
it could query what the capabilities of the device were, and report that 
back to SOS.

I'm asking because of the CFFA3000 card that Rich Dreher is building 
now.  It's different than the original CFFA in that its only interface 
to the world is the SmartPort protocol.  So... such a device driver 
would need to be written in order to make use of it in the ///.  It 
sounds like an interesting challenge, but surely it was solved somewhere 
down the line in order to support something...?

- David

From marraccini at acm.org  Wed Aug 17 11:58:01 2011
From: marraccini at acm.org (Jeff Marraccini)
Date: Wed, 17 Aug 2011 11:58:01 -0400
Subject: [Apple3-L] Did a SmartPort driver ever get written for the ///?
In-Reply-To: <4E4BE15F.6020609@attglobal.net>
References: <4E4BE15F.6020609@attglobal.net>
Message-ID: <CAJ+B+RLFy8vqqu1bMLyZP7kqKEZJMHWNCTwM-k7qQwR=r-3Zgg@mail.gmail.com>

David,

I never heard of one :(

Thanks,

Jeff

On Wed, Aug 17, 2011 at 11:42 AM, Cathy Schmidt <david4602 at gmail.com> wrote:
> A question for the Sarasours out there... did a SmartPort driver ever get
> written for the ///? ?The way this would be useful would be if a SmartPort
> adapter were plugged into an expansion slot, the standard SmartPort/ProDOS
> interface could be rerouted through a SOS block device driver. ?It wouldn't
> even need to be specific to a particular device... it could query what the
> capabilities of the device were, and report that back to SOS.
>
> I'm asking because of the CFFA3000 card that Rich Dreher is building now.
> ?It's different than the original CFFA in that its only interface to the
> world is the SmartPort protocol. ?So... such a device driver would need to
> be written in order to make use of it in the ///. ?It sounds like an
> interesting challenge, but surely it was solved somewhere down the line in
> order to support something...?
>
> - David
> _______________________________________________
> Apple3-L mailing list
> Apple3-L at mailman1.altair.com
> https://mailman1.altair.com/mailman/listinfo/apple3-l
>

From david.ottalini at verizon.net  Wed Aug 17 12:11:45 2011
From: david.ottalini at verizon.net (David Ottalini)
Date: Wed, 17 Aug 2011 12:11:45 -0400
Subject: [Apple3-L] Did a SmartPort driver ever get written for the ///?
In-Reply-To: <CAJ+B+RLFy8vqqu1bMLyZP7kqKEZJMHWNCTwM-k7qQwR=r-3Zgg@mail.gmail.com>
References: <4E4BE15F.6020609@attglobal.net>
	<CAJ+B+RLFy8vqqu1bMLyZP7kqKEZJMHWNCTwM-k7qQwR=r-3Zgg@mail.gmail.com>
Message-ID: <A312C9EC-D308-4995-A9D7-F25D3FA587C2@verizon.net>

Don't believe one ever existed...

SO the question is...how hard would it be to write one?

Dave Ottalini

Sent from my iPad

On Aug 17, 2011, at 11:58 AM, Jeff Marraccini <marraccini at acm.org> wrote:

> David,
> 
> I never heard of one :(
> 
> Thanks,
> 
> Jeff
> 
> On Wed, Aug 17, 2011 at 11:42 AM, Cathy Schmidt <david4602 at gmail.com> wrote:
>> A question for the Sarasours out there... did a SmartPort driver ever get
>> written for the ///?  The way this would be useful would be if a SmartPort
>> adapter were plugged into an expansion slot, the standard SmartPort/ProDOS
>> interface could be rerouted through a SOS block device driver.  It wouldn't
>> even need to be specific to a particular device... it could query what the
>> capabilities of the device were, and report that back to SOS.
>> 
>> I'm asking because of the CFFA3000 card that Rich Dreher is building now.
>>  It's different than the original CFFA in that its only interface to the
>> world is the SmartPort protocol.  So... such a device driver would need to
>> be written in order to make use of it in the ///.  It sounds like an
>> interesting challenge, but surely it was solved somewhere down the line in
>> order to support something...?
>> 
>> - David
>> _______________________________________________
>> Apple3-L mailing list
>> Apple3-L at mailman1.altair.com
>> https://mailman1.altair.com/mailman/listinfo/apple3-l
>> 
> _______________________________________________
> Apple3-L mailing list
> Apple3-L at mailman1.altair.com
> https://mailman1.altair.com/mailman/listinfo/apple3-l

From david at attglobal.net  Wed Aug 17 12:13:15 2011
From: david at attglobal.net (David Schmidt)
Date: Wed, 17 Aug 2011 12:13:15 -0400
Subject: [Apple3-L] Did a SmartPort driver ever get written for the ///?
In-Reply-To: <CAJ+B+RLFy8vqqu1bMLyZP7kqKEZJMHWNCTwM-k7qQwR=r-3Zgg@mail.gmail.com>
References: <4E4BE15F.6020609@attglobal.net>
	<CAJ+B+RLFy8vqqu1bMLyZP7kqKEZJMHWNCTwM-k7qQwR=r-3Zgg@mail.gmail.com>
Message-ID: <4E4BE89B.9040407@attglobal.net>

Yeah, Me neither.  I'll poke around the WAP disks to see if anything 
sticks out, but I'm not overly optimistic.

It seems like it ought to be possible to "wrap" the ProDOS calling 
convention with a block device driver - storing the parameters to the 
call in the driver's zero page ($42-$47), enabling the $C800 space, and 
calling the card's entry points; copying the data back out when done. 
Buffers would always need to be in the caller's bank... that could get 
interesting.  Anyway, I'm in the early stages of understanding all that 
would have to go on, so no one needs to hold their breath.

- David

On 8/17/2011 11:58 AM, Jeff Marraccini wrote:
> David,
>
> I never heard of one :(
>
> Thanks,
>
> Jeff
>
> On Wed, Aug 17, 2011 at 11:42 AM, [David] Schmidt wrote:
>> A question for the Sarasours out there... did a SmartPort driver ever get
>> written for the ///?  The way this would be useful would be if a SmartPort
>> adapter were plugged into an expansion slot, the standard SmartPort/ProDOS
>> interface could be rerouted through a SOS block device driver.  It wouldn't
>> even need to be specific to a particular device... it could query what the
>> capabilities of the device were, and report that back to SOS.
>>
>> I'm asking because of the CFFA3000 card that Rich Dreher is building now.
>>   It's different than the original CFFA in that its only interface to the
>> world is the SmartPort protocol.  So... such a device driver would need to
>> be written in order to make use of it in the ///.  It sounds like an
>> interesting challenge, but surely it was solved somewhere down the line in
>> order to support something...?
>>
>> - David

From david at attglobal.net  Wed Aug 24 09:21:58 2011
From: david at attglobal.net (David Schmidt)
Date: Wed, 24 Aug 2011 09:21:58 -0400
Subject: [Apple3-L] Updated CFFA driver available
Message-ID: <4E54FAF6.7010306@attglobal.net>

Thanks to the hard work of Dale Jackson and Dave Schmenk, there's a new 
driver available for the CFFA (rev1 and rev2) boards.  Dave took Dale's 
driver, combined the support for both board revisions, and sped things 
up a little more.

I've posted the driver package, including an updated CFFA Utilities disk 
with the new driver pre-configured for slot 1 on apple3.org.  Get it here:

http://apple3.org/iiisoftware.html

Scroll down to "System - Drivers"; you'll find the CFIDE_140A.zip package.

In Dave Schmenk's own words:

   I took Dale's latest drivers for the CFFA with and without the 
version 2 CPLD for fast and throttled transfers, worked over the source 
to make it easier to read, cleaned up some code paths,  rewrote the two 
transfer routines and combined them into one driver.  It also retains 
compatibility with the current CF data layout.

   The driver defaults to slot 1 and slow transfers.  This will work on 
the later rev CFFA, but is the safest default.  To change the driver to 
use the fast routines, enter the System Configuration Program, load the 
drivers, install the CFIDE.DRIVER driver, edit the driver configuration 
bytes for .CFIDE1 and set the third byte to a 1.  You can change the 
slot assignment in the SCP also.

   This is ALPHA so be sure not to blow anything important away (I live 
on the edge and test on my development machine).  All my CFFAs are Rev 2 
so I can't promise it works on a Rev 1.

   I timed boot times using the slow and fast xfer options and saw about 
a 2 second boot time improvement.  26.3 vs 24.2 seconds.  This included 
the floppy part of the boot all the way up to the Pascal menu (Pascal 
was loaded on the CFFA).

From marraccini at acm.org  Wed Aug 24 09:40:22 2011
From: marraccini at acm.org (Jeff Marraccini)
Date: Wed, 24 Aug 2011 09:40:22 -0400
Subject: [Apple3-L] Updated CFFA driver available
In-Reply-To: <4E54FAF6.7010306@attglobal.net>
References: <4E54FAF6.7010306@attglobal.net>
Message-ID: <CAJ+B+RLEm6Em3Y1ivsCX9tKmKkgRHOLtfzO=pMeaV8twChc-Qg@mail.gmail.com>

This is wonderful news, thanks so much all of you!  I will upgrade
when I get home this weekend.

On Wed, Aug 24, 2011 at 9:21 AM, David Schmidt <david at attglobal.net> wrote:
> Thanks to the hard work of Dale Jackson and Dave Schmenk, there's a new
> driver available for the CFFA (rev1 and rev2) boards. ?Dave took Dale's
> driver, combined the support for both board revisions, and sped things up a
> little more.
>
> I've posted the driver package, including an updated CFFA Utilities disk
> with the new driver pre-configured for slot 1 on apple3.org. ?Get it here:
>
> http://apple3.org/iiisoftware.html
>
> Scroll down to "System - Drivers"; you'll find the CFIDE_140A.zip package.
>
> In Dave Schmenk's own words:
>
> ?I took Dale's latest drivers for the CFFA with and without the version 2
> CPLD for fast and throttled transfers, worked over the source to make it
> easier to read, cleaned up some code paths, ?rewrote the two transfer
> routines and combined them into one driver. ?It also retains compatibility
> with the current CF data layout.
>
> ?The driver defaults to slot 1 and slow transfers. ?This will work on the
> later rev CFFA, but is the safest default. ?To change the driver to use the
> fast routines, enter the System Configuration Program, load the drivers,
> install the CFIDE.DRIVER driver, edit the driver configuration bytes for
> .CFIDE1 and set the third byte to a 1. ?You can change the slot assignment
> in the SCP also.
>
> ?This is ALPHA so be sure not to blow anything important away (I live on the
> edge and test on my development machine). ?All my CFFAs are Rev 2 so I can't
> promise it works on a Rev 1.
>
> ?I timed boot times using the slow and fast xfer options and saw about a 2
> second boot time improvement. ?26.3 vs 24.2 seconds. ?This included the
> floppy part of the boot all the way up to the Pascal menu (Pascal was loaded
> on the CFFA).
> _______________________________________________
> Apple3-L mailing list
> Apple3-L at mailman1.altair.com
> https://mailman1.altair.com/mailman/listinfo/apple3-l
>

